User positive approval and authentication services (upaas)

ABSTRACT

The invention provides Users of Retail Payment and Identification instruments with the ability to review transaction details and approve transaction by capturing UVM in User controlled environment and Issuers of these instruments with the ability to positively authenticate Users in Issuer controlled environment. The invention accounts for real time legacy or non-legacy processing systems to provide an authorization request from POA to Issuer Host. The invention introduces two UPAAS components—User Gateway and User Application. The UPAAS User Gateway is implemented in an Issuer controlled environment enabling interface between Issuer legacy Host and UPAAS User Applications. The UPAAS User Application can be implemented on any device supporting communication protocol such as TCP/IP without any hardware changes enabling the User to login to UPAAS User Gateway, review and approve or decline a specific transaction in real time by entering UVM, such as PIN, for User authentication purposes.

BACKGROUND OF THE INVENTION

The foundation of the invention was a realization of the existingproblems and opportunities that emerging technologies are bringing alongin the areas of transaction approval and User authentication for RetailPayment and Identification transactions.

Recognized Problems

-   -   For a number of years the Card industry has been facing demands        for a stronger Cardholder authentication and better protection        of User and Payment instrument proprietary information. The Card        industry responded with EMV-chip cards where an offline PIN was        introduced replacing or substituting signature as CVM. An        Offline PIN is significantly more reliable than a signature        however it came with a price: the cost of EMV implementation and        maintenance is significant and is billed to all parties:        Merchants/POA, Acquirer, Network and Issuers. Another downside        is that the PIN remained captured at POA and User verification        remained within the POA environment. To mitigate the risks the        Payment Card. Industry (PCI) introduced PED and Data Security        standards which improved security however also further increased        the cost of implementation and maintenance. Verification of a        CVM at the POA means that the Issuer is advised of the        Cardholder Verification Result, but not actually performing User        authentication, which opens up doors for “wedge” (man-in-the        middle) attacks and other fraud risks.    -   The personal and traveler's cheques industry currently provides        the ability to validate the cheques or drafts being presented,        verify the history of the User (account holder), to validate the        Routing Number and verify the User Account number status,        however User authentication is not currently available for        cheque transactions which along with the cost of Cheque        Verification processing contributed to the constant decline of        cheque use.    -   Users of identification instruments like Insurance and Health        cards are either not authenticated at all or the authentication        is performed by the accepter using other pictured IDs, like a        Driver's license.

Perceived Opportunities

-   -   Mass adoption of data enabled devices enables a reach to Users        of Retail payment and Identification instruments in real time,        anytime, anywhere enabling User transaction approval and User        authentication in Issuer controlled environment that was        previously not possible.    -   Providing Users of Payment and Identification instruments with        the ability to review and approve transactions and enter UVMs at        the devices they control improves the security of UVM and        effectively externalizes User Transaction approval and User        authentication from POA/accepter's environment thus removing the        line between User (Cardholder) Present and User (Cardholder) Not        Present transactions.    -   User Transaction approval and User authentication naturally        belong to Issuer environment. Ensuring this decouples the        Payment Instrument information (processed in authorization        request/response) from User Authentication information which        significantly contributes to fraud prevention.

BRIEF SUMMARY OF THE INVENTION

The invention accounts for legacy or non-legacy real time processingsystems providing transaction details captured at a POA to the IssuerHost through an Acquirer and when appropriate Network environment in theform of transaction authorization request. At a minimum the Transactionauthorization request provides Payment or Identification Instrument ID(i.e. Primary Account Number), POA information (i.e. Accepter Name andLocation) and Transaction Amount.

The invention introduces two components:

-   -   UPAAS User Gateway (125) implemented in Issuer controlled        environment which facilitates processing of Approval        Request/Response between Issuer Card, Card-less or ID Legacy        systems and UPAAS User Application (122).    -   UPAAS User Application (122) which can be implemented on any        device supporting appropriate data communication protocol such        as TCP/IP. It provides Users with ability to review and accept        or decline the transaction once the authorization request is        received by the Issuer. The User confirms acceptance of a        transaction by entering UVM which is encrypted by the UPAAS User        application and forwarded to Issuer for User authentication and        Issuer approval.

The invention externalizes User Authentication from a legacy POA,Acquiring and Network systems and enables Issuers of Retail Payment andIdentification instruments with ability to positively authenticate Usersof these instruments in real time in Issuer controlled environmentwithout any involvement of POA, acquiring and network systems in Userauthentication.

The invention externalizes User transaction approval from a legacy POAand enables Issuers of Retail Payment and Identification instrumentswith ability to request a transaction approval from Users in real timeafter the Issuer receives authorization request for the transaction andbefore the Issuer approval is granted. As a result of this the inventionmakes the Issuer approval contingent to the User's approval ensuringnon-repudiation of Issuer approved transactions.

The invention provides Users of Retail Payment and Identificationinstruments with the ability to review and approve or declinetransaction and capture UVM on self controlled devices, thus decouplingPoint of (Instrument) Acceptance from Point of Transaction Approval andPoint of User Authentication, which effectively removes the line betweenUser Present and User Not-Present transactions.

By externalizing User Authentication from the POA the invention ensuresthat the Payment Instrument information (i.e. Primary Account Number)and User Verification information (i.e. PIN) are neither captured norprocessed together at any point of the transaction life cycle. Thisprevents the association of the Instrument and UVM information by anyonebut the User and Issuer, thus reducing the possibility of creating andusing the counterfeit instruments.

The major benefits of the invention are the following:

-   -   No physical changes or modifications are required to devices        where the UPAAS User Application is implemented.    -   Issuer performs User Authentication in its own environment which        is currently possible for ATM on-us transactions only. The same        increases transaction security and simplifies implementation and        change management: any modification or improvements can be done        without impacts to Merchant, Acquirer and Network environments.    -   Accepters of Payment or Identification instruments are spared        from implementing and maintaining User Authentication functions        at their POA devices while enjoying increased guarantee of        payment and non-repudiation.    -   Acquirer processors and Networks are spared from, implementing        and maintaining Industry mandates related to User authentication        and data security standards including but not limited to secure        UVM capture, encryption and support of associated key        infrastructure.    -   Users are provided with the opportunity to review and approve or        decline the transaction in a self controlled environment and the        ability to identify and decline a fraudulent or incorrectly        processed transaction request before it is processed by the        Issuer Host.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The drawings provided herein present possible implementation scenariosof the invention. These scenarios should be taken as examples only andthey are not meant to limit implementation of the invention beyondpresented scenarios, nor limit the scope, implementation type orconfiguration of the invention providing that the spirit of theinvention is preserved as set forth in the invention claims.

FIG. 1 presents a process flow of the embodiment enabling transactionapprovals to Users and User Authentication to Issuers of non-proprietaryCard. Retail Payment Instruments in legacy Open Loop scenario whereIssuer uses its legacy system for PIN verification.

FIG. 2 presents a process flow of the embodiment enabling transactionapprovals to Users and User Authentication to Issuers of non-proprietaryCard Retail Payment Instruments in legacy Open Loop scenario whereIssuer uses UPAAS for UVM verification.

FIG. 3 presents a process flow of the embodiment enabling transactionapproval to Users and User Authentication to Issuers of proprietary CardRetail Payment Instruments in legacy Closed Loop scenario where Issueruses UPAAS for UVM verification.

FIG. 4 presents a process flow of the embodiment enabling transactionapproval to Users and User Authentication to Issuers of Card-less RetailPayment Instruments in legacy Open Loop scenario where Issuer uses UPAASfor UVM verification.

FIG. 5 presents a process flow of the embodiment enabling transactionapproval to Users and User Authentication to Issuers of Card-less RetailPayment Instruments in legacy Closed Loop scenario where Issuer usesUPAAS for UVM verification.

FIG. 6 presents a process flow of the embodiment enabling transactionapproval to Users and User Authentication to Issuers when IdentificationInstruments are used in legacy Closed Loop scenario where Issuer usesUPAAS for UVM verification.

DETAILED DESCRIPTION OF THE INVENTION

Details of end-to end transaction flow and User transaction approval andUser Authentication processes are as presented in FIGS. 1-6 andcorresponding descriptions in the tables below.

TABLE 1 Detailed description of process flow and relevant business logicexercised in UPAAS implementation scenario presented in FIG. 1 whereUser Approval and Authentication processes are exercised for Card retailpayment transactions initiated and processed in an Open Loop Card Legacyenvironment where Issuer verifies PIN in its legacy environment. 1110 Ifunattended POA 111 swipes card; If eCommerce transaction 111 enters Cardnumber and other requested information (i.e. CVV2/CVC2) as requested bye- Commerce web site. 2130 If attended POA 213 swipes card and entersamount; If MOTO 213 enters Card number and amount; 1117 111 activates122 in order to establish connection with 125 1227 122 sends LoginRequest to 125 where User Name is implicitly provided by 122. Subject toIssuer requirements Password is either entered by 111 or implicitlyprovided by 122 1258 125 verifies User Name & Password, checks 111status and if valid sends Login Response to 122/establishes an opensession and awaits for Approval Request from 116 2141 214 sendsAuthorization Request to 215 with appropriate 214 information,Transaction Amount and captured Card Information 2151 215 enrichesAuthorization Request with appropriate acquirer and merchant informationand Forwards Authorization Request to 315 3151 315 identifies 116 basedon PAN BIN and forwards Authorization Request to 116 1163 116 checks PANprovided in 3151 to determine if 111 is registered for UPAAS servicesand if yes sends Approval Request to 125 with PAN, 214 information andTransaction Amount 1253 125 identifies 122 using PAN, checks 122 statusand if valid sends Approval Request to 122 1114 111 reviews 214 Name &Location, Transaction Amount as received in 1253 and displayed by 122and confirms acceptance by entering PIN and “From Account Type” 1224 122sends Approval Response to 125 with encrypted PIN Block and “FromAccount” type 1254 125 sends Approval Response to 116 with encrypted PINBlock and “From Account” type 1165 116 sends PIN Verification Request to109 1096 109 verifies PIN and sends PIN Verification Response to 1161161 116 sends Fund Authorization Request to 118 1182 118 verifiesaccount balance/open to buy and sends Authorization Response to 116 1162116 sends Authorization Response to 315 3152 315 forwards AuthorizationResponse to 215 2152 215 forwards Authorization Response to 214 at whichpoint goods or services are granted to 111 1169 Subject to IssuerRequirement 116 sends Authorization Advice to 125 1259 If 1169 receivedfrom 116 then 125 sends Authorization Advice to 122 at which point thesession is closed

TABLE 2 Detailed description of process flow and relevant business logicexercised in UPAAS implementation scenario presented in FIG. 2 whereUser Approval and Authentication processes are exercised for Card retailpayment transactions initiated at and processed through an Open LoopCard Legacy environment where UVM Verification is completed between theUPAAS User Gateway and Issuer UVM Verification system. 1110 Ifunattended POA 111 swipes card; if eCommerce transaction 111 enters Cardnumber and other requested information (i.e. CVV2/CVC2) as requested bye- Commerce web site. 2130 If attended POA 213 swipes card and entersamount; If MOTO 213 enters Card number and amount; 1117 111 activates122 in order to establish connection with 125 1227 122 sends LoginRequest to 125 where User Name is implicitly provided by 122. Subject toIssuer requirements Password is either entered by 111 or implicitlyprovided by 122 1258 125 verifies User Name & Password, checks 111status and if valid sends Login Response to 122/establishes an opensession and awaits for Approval Request from 116 2141 214 sendsAuthorization Request to 215 with appropriate 214 information,Transaction Amount and captured Card Information 2151 215 enrichesAuthorization Request with appropriate acquirer and merchant informationand Forwards Authorization Request to 315 3151 315 identifies 116 basedon PAN BIN and forwards Authorization Request to 116 1163 116 checks PANprovided in 3151 to determine if 111 is registered for UPAAS servicesand if yes sends Approval Request to 125 with PAN, 214 information andTransaction Amount 1253 125 identifies 122 using PAN, checks 122 statusand if valid sends Approval Request to 122 1114 111 reviews 214 Name &Location, Transaction Amount as displayed by 122 and confirms acceptanceby entering UVM and “From Account Type” 1224 122 sends Approval Responseto 125 with Encrypted UVM and “From Account” type 1255 125 sends UVMVerification Request to 109 1096 109 verifies UVM and sends UVMVerification Response to 125 1254 125 sends Approval Response to 116with “From Account” type 1161 116 sends Fund Authorization Request to118 1182 118 verifies account balance/open to buy and sendsAuthorization Response to 116 1162 116 sends Authorization Response to315 3152 315 forwards Authorization Response to 215 2152 215 forwardsAuthorization Response to 214 at which point goods or services aregranted to 111 1169 Subject to Issuer Requirement 116 sendsAuthorization Advice to 125 1259 If 1169 received from 116 125 sendsAuthorization Advice to 122 at which point the session is closed

TABLE 3 Detailed description of process flow and relevant business logicexercised in UPAAS implementation scenario presented in FIG. 3 whereUser Approval and Authentication processes are exercised for Card retailpayment transactions initiated at and processed through a Closed LoopCard Legacy environment where UVM Verification is completed between theUPAAS User Gateway and Issuer UVM Verification system. 1110 Ifunattended POA 111 swipes card. 2130 If attended POA 213 swipes card andenters amount 1117 111 activates 122 in order to establish connectionwith 125 1227 122 sends Login Request to 125 where User Name isimplicitly provided by 122. Subject to Issuer requirements Password iseither entered by 111 or implicitly provided by 122 1258 125 verifiesUser Name & Password, checks 111 status and if valid sends LoginResponse to 122/establishes an open session and awaits for ApprovalRequest from 116 2141 214 sends Authorization Request to 215 withappropriate 214 information, Transaction Amount and captured CardInformation 2151 215 enriches Authorization Request with appropriateacquirer and merchant information and Forwards Authorization Request to116 1163 116 checks PAN provided in 3151 to determine if 111 isregistered for UPAAS services and if yes sends Approval Request to 125with PAN, 214 information and Transaction Amount 1253 125 identifies 122using PAN, checks 122 status and if valid sends Approval Request to 1221114 111 reviews 214 Name & Location, Transaction Amount as displayed by122 and confirms acceptance by entering UVM and “From Account Type” 1224122 sends Approval Response to 125 with UVM Block Encrypted and “FromAccount” type 1255 125 sends UVM Verification Request to 109 1096 109verifies UVM and sends UVM Verification Response to 125 1254 125 sendsApproval Response to 116 with “From Account” type 1161 116 sends FundAuthorization Request to 118 1182 118 verifies account balance/open tobuy and sends Authorization Response to 116 1162 116 sends AuthorizationResponse to 215 2152 215 forwards Authorization Response to 214 at whichpoint goods or services are granted to 111 1169 Subject to IssuerRequirement 116 sends Authorization Advice to 125 1259 If 1169 receivedfrom 116 then 125 sends Authorization Advice to 122 at which point thesession is closed

TABLE 4 Detailed description of process flow and relevant business logicexercised in UPAAS implementation scenario presented in FIG. 4 whereUser Approval and Authentication processes are exercised for Card-lessretail payment transactions initiated at and processed through an OpenLoop Legacy environment where UVM Verification is completed between theUPAAS User Gateway and Issuer UVM Verification system. 2330 233 entersamount and Cheque number (manual entry or bar code read) 1317 131activates 122 in order to establish connection with 125 1227 122 sendsLogin Request to 125 where User Name is implicitly provided by 122.Subject to Issuer requirements Password is either entered by 131 orimplicitly provided by 122 1258 125 verifies User Name & Password,checks 131 status and if valid sends Login Response to 122/establishesan open session and awaits for Approval Request from 136 2341 234 sendsCheque Verification Request to 235 with appropriate 234 information,Transaction Amount and captured Cheque Information 2351 235 sends ChequeVerification Request with appropriate acquirer and merchant informationto 335 3351 335 identifies 136 based on cheque number and forwardsCheque Verification Request to 136 1363 136 checks Cheque Numberprovided in 3351 to verify if 131 is registered for UPAAS services andif yes sends Approval Request to 125 with Cheque Number, 234 informationand Transaction Amount 1253 125 identifies 122 using Cheque Number,checks 122 status and if valid sends Approval Request to 122 1314 131reviews Cheque Number, 234 Name & Location, Transaction Amount asdisplayed by 122 and confirms acceptance by entering UVM 1224 122 sendsApproval Response to 125 with encrypted UVM Block 1255 125 sends UVMVerification Request to 109 1096 109 verifies UVM and sends UVMVerification Response to 125 1254 125 sends Approval Response to 1361361 136 sends Fund Authorization Request to 138 1382 138 verifiesaccount balance against requested amount and sends Fund AuthorizationResponse to 136 1362 136 sends Cheque Verification Response to 335 3352335 forwards Cheque Verification Response to 235 2352 235 forwardsCheque Verification Response to 234 at which point goods or services orcash withdrawal is granted to 131 1369 Subject to Issuer Requirement 136sends Cheque Verification Advice to 125 1259 If 1369 received from 136then 125 sends Cheque Verification Advice to 122 at which point thesession is closed

TABLE 5 Detailed description of process flow and relevant business logicexercised in UPAAS implementation scenario presented in FIG. 5 whereUser Approval and Authentication processes are exercised for Card-lessretail payment transactions initiated at and processed through a CloseLoop Legacy environment where UVM Verification is completed between theUPAAS User Gateway and Issuer UVM Verification system. 2330 233 entersamount and Cheque number (manual entry or bar code read) 1317 131activates 122 in order to establish connection with 125 1227 122 sendsLogin Request to 125 where User Name is implicitly provided by 122.Subject to Issuer requirements Password is either entered by 131 orimplicitly provided by 122 1258 125 verifies User Name & Password,checks 131 status and if valid sends Login Response to 122/establishesan open session and awaits for Approval Request from 136 2341 234 sendsCheque Verification Request to 235 with appropriate 234 information,Transaction Amount and captured Cheque Information 2351 235 sends ChequeVerification Request with appropriate acquirer and merchant informationto 136 1363 136 checks Cheque Number provided in 3351 to verify if 131is registered for UPAAS services and if yes sends Approval Request to125 with Cheque Number, 234 information and Transaction Amount 1253 125identifies 122 using Cheque Number, checks 122 status and if valid sendsApproval Request to 122 1314 131 reviews Cheque Number, 234 Name &Location, Transaction Amount as displayed by 122 and confirms acceptanceby entering UVM 1224 122 sends Approval Response to 125 with encryptedUVM Block 1255 125 sends UVM Verification Request to 109 1096 109verifies UVM and sends UVM Verification Response to 125 1254 125 sendsApproval Response to 136 1361 136 sends Fund Authorization Request to138 1382 138 verifies account balance against requested amount and sendsFund Authorization Response to 136 1362 136 sends Cheque VerificationResponse to 235 2352 235 forwards Cheque Verification Response to 234 atwhich point goods or services or cash withdrawal is granted to 131 1369Subject to Issuer Requirement 136 sends Cheque Verification Advice to125 1259 If 1369 received from 136 then 125 sends Cheque VerificationAdvice to 122 at which point the session is closed

TABLE 6 Detailed description of process flow and relevant business logicexercised in UPAAS implementation scenario presented in FIG. 6 whereUser Approval and Authentication processes are exercised forIdentification instrument transactions initiated at and processedthrough a Close Loop processing environment where UVM Verification iscompleted between the UPAAS User Gateway and Issuer UVM Verificationsystem 2430 243 enters ID Number (manually or through bar or magstriperead) 1417 141 activates 122 in order to establish connection with 1251227 122 sends Login Request to 125 where User Name is implicitlyprovided by 122. Subject to Issuer requirements Password is eitherentered by 141 or implicitly provided by 122 1258 125 verifies User Name& Password, checks 141 status and if valid sends Login Response to122/establishes an open session and awaits for Approval Request from 1462441 244 sends ID Verification Request to 245 with appropriate 244information and captured ID Information 2451 245 forwards IDVerification Request to 146 1463 146 checks ID provided in 2451 todetermine if 141 is registered for UPAAS services and if yes sendsApproval Request to 125 with 214 information 1253 125 identifies 122using ID, checks its status and if valid sends Approval Request to 1221414 141 reviews 244 Name & Location as displayed by 122 and confirmsacceptance by entering UVM 1224 122 sends Approval Response to 125 withencrypted UVM Block 1255 125 sends UVM Verification Request to 109 1096109 verifies UVM and sends UVM Verification Response to 125 1254 125sends Approval Response to 146 1462 146 sends ID Verification Responseto 245 2452 245 forwards ID Verification Response to 244 at which pointUser verification has been confirmed 1469 Subject to Issuer Requirement146 sends ID Verification Advice to 125 1259 If 1469 received from 146then 125 sends ID Verification Advice to 122 at which point the sessionis closed

1. A method of enabling issuers of retail payment and identificationinstruments to request and receive approval from users of theseinstruments in transaction real time to authenticate the users,comprising: sending a request, from an issuer host, to a user comprisinga request for the user to provide information of one or more dataconnected devices during a registration process wherein this informationis associated with a user ID and used for processing a user approvalrequest and response; sending download instructions for a userapplication to the user and enabling the user to download the userapplication to one or more of the data connected devices over a wired orwireless communication protocol; providing the user with an ability toactivate the user application using a one-time authentication key or amethod selected by the issuer; receiving, on the issuer host, atransaction authorization request from at least one of a network or anacquirer, the transaction authorization request comprising informationdescribing a presently-unapproved transaction; sending the user approvalrequest in transaction real time requesting the user to approve ordecline the transaction and prompting the user to enter a userverification method key; and sending the user approval response to theissuer host for approval by the issuer.
 2. The method of claim 1,wherein the user approval request includes at least the user ID, anaccepter name and location, and a transaction currency and amount. 3.The method of claim 1, wherein the user approval request requestsadditional information from the user including at least one accounttype.
 4. The method of claim 1, wherein the user approval responseindicates whether the user accepted or declined the transaction, whereinuser acceptance of the transaction includes an encrypted userverification method key block.
 5. The method of claim 1, furthercomprising: capturing the user verification method key for approvedtransactions wherein subject to issuer discretion the user verificationmethod key may information known only to the user; encrypting the userverification method key using either symmetric or asymmetric keys;sending the encrypted user verification method key in the user approvalresponse without including any other information that can be associatedwith the identity of the user identity or the user payment andidentification instrument information; decrypting the user verificationmethod key block received in the user approval response using eithersymmetric or asymmetric keys; and verifying an authenticity of the user.